Revocable Signature Scheme with Implicit and Explicit Certificates

This paper addresses the certificate revocation problem and proposes the first revocable pairing-based signature scheme with implicit and explicit certificates (IE-RCBS-kCAA). We should no longer discuss whether to revoke certificates but how to do it effectively, ensuring both the scalability of the revocation operation and the non-repudiation of the signature in the short or long term. Under the computational difficulty assumptions of the modified collusion attack algorithm with k traitors (k-mCAA) and discrete logarithm (DL) problems, we demonstrate that our scheme is secure against existential unforgeability under chosen message attacks (EUF-IERCBS-kCAA-CMA) in a random oracle model. The proposed solution is scaled and allows the use of many trusted status authorities that issue explicit short-term certificates confirming the validity of explicit long-term certificates. Furthermore, we demonstrate that our signature scheme has a short-term non-repudiation property for the shell validity model.


Introduction
Digital signatures are a critical component that ensure the integrity, authenticity and non-repudiation of electronic documents.In public key cryptography (PKC), a digital signature is considered valid if it is mathematically correct and a related certificate is valid.The certificates are issued for a limited period (usually two years), they can be revoked (e.g., a signer's private key is compromised) and in most cases, a user certificate is issued by an intermediate CA (certificate authority), and other certificates are issued by another intermediate CA or by a root CA with a self-signed certificate.The root CA is considered a trust anchor.All certificates between an end-entity certificate and a trust anchor certificate form the trusted certificate path.The validation of this chain is a challenging task.
Three models for certificate validation exist [1].In the first one, called the shell model, the certificate is valid as long as all the certificates in the certification path are valid when the signature is verified.The second one is the modified shell model.In this model, the signing time is the basis for decision making about the signature validity (this requires a timestamp).The third model is the chain model: once a signature is valid at signing time, it remains valid all the time.The chain model can only provide non-repudiation of property over a long period of time [1,2].
The purpose of certificate validation is to confirm the authenticity of the public key, i.e., to provide proof that the public key belongs to the signer and that the associated private key was under the sole control of an owner at the moment of signature creation.The process of verifying certificates for signatures that need to be valid for a long period of time is one of the main difficulties when implementing and managing a public key infrastructure.The authenticity of a public key in a public key cryptosystem can be achieved in two ways: either explicitly or implicitly.During explicit authentication, the public key authenticity can be verified directly using the certificate issued by a CA.In implicit authentication, the secret certificate issued by a CA (i.e., partial or complete private key) can be verified indirectly during signature verification or decryption operation.Combining both approaches and obtaining cryptographic schemes based on explicit and implicit certificates is another possible solution (e.g., T. Hyla et al. [3]).
It seemed that the certificate validation problem had been solved in 1984 when Shamir [4] introduced a new identity-based public key cryptography (ID-PKC) concept utilizing a user's publicly known identity information as her/his public key.Since that time, many schemes based on that concept have been proposed.First came certificateless public key cryptography (CL-PKC), which removed the key escrow problem, one of the major problems in ID-PKC.Next, (implicit) certificate-based public key cryptography (IC-PKC) schemes were proposed.Compared to CL-PKC, IC-PKC schemes are resistant to public key replacement attacks.The certificate is implicit because it must be kept secret and is not used directly during signature verification.In other words, the implicit certificate is a partial secret key sent to the user by a trusted authority (TA) that, in comparison to CL-PKC schemes, additionally binds the user's identity with its public key and the parameters of the trusted authority.Note that some authors do not use the word "implicit", which could be misleading as someone might think that certificates are always public.
The great interest shown in the ID-PKC, CL-PKC and IC-PKC schemes is because they eliminate explicit certificates from the encryption or signature schemes and allow the need to manage the status of certificates to be dispensed with.In practice, this is not the case, as the problem of certificate status management is shifted to the user identity management level [5,6].In addition, this generates problems with public key distribution, such as vulnerability to public key replacement attacks.As a result, key invalidation in ID-PKC, CL-PKC and IC-PKC schemes can be even more cumbersome than in traditional PKC-based cryptosystems.

Related Works
The digital signature schemes must include a revocation mechanism to support nonrepudiation and achieve Girault trust level 3 (see Girault,M. [7]).The revocation mechanism in identity-based certificates or based on implicit certificate schemes is implemented through a few techniques: using an online mediator, periodically updating the user's secret using a secret channel and using time keys that can be sent using a public channel.
In the online mediator (SEM, Security Mediator) technique [8,9], a user's partial private key is divided into two parts.One part is sent to the user and one to the SEM.The advantage of this approach is instantaneous revocation.The main drawbacks of this approach are the need for a secure (confidential) channel, and that the user cannot create a signature independently.In addition, the SEM must store a large amount of partial secret keys.Secondly, it is possible to generate private keys over regular periods [10][11][12].When revocation of users is needed, the trusted authority (TA) just stops updating users' partial private keys.The main drawback is the need for secure channels between users and TA.
In 2001, Boneh and Franklin [13] proposed a method in which a trusted private key generator (PKG) periodically updates private keys for all non-revoked users.Boldyreva et al. [14] introduced the first scalable revocable identity-based encryption scheme.The scheme was later improved by Libert and Vergnaud [15] and by Seo and Emura [16].In 2012, Tseng and Tsai proposed efficient revocable identity-based encryption [17] and signature schemes [18].They used a different method of private key construction, where the private key consists of a fixed initial private key and a time key, which is issued periodically by the PKG for non-revoked users.The key can be sent using a public channel.Their work was later reviewed by [19].Chen et al. [20] proposed a selective-ID secure revocable identity-based encryption (RIBE) scheme from lattices.Cheng et al. [21] presented an adaptive-ID version of the [20] scheme.Lee et al. in [22,23] constructed a RIBE scheme based on pairings using the subset difference method.
In 2014, Sun et al. [24] proposed a revocable certificateless signature (RCLS) scheme in which the TA produces an initial partial private key and a time key corresponding to each period.The time key is transmitted over a public channel.Next, Sun and Shen [25] and Sun et al. [26] proposed a revocable certificateless signature (RCLS) scheme without the use of bilinear pairings.
In 2017, Jia et al. [27] proposed an efficient revocable identity-based signature (RIBS) scheme in which the revocation functionality is outsourced to a cloud revocation server.In their solution, a short-term key (time key) is issued by the cloud server instead of KGC.Recently, a similar solution based on semi-trusted cloud revocation agents (s-CRAs) was used by Ma et al. [28].

Motivation and Contribution
This paper proposes a new revocable signature IE-RCBS-kCAA scheme with implicit and two explicit (short-and long-term) certificates, which is secure in the random oracle model under the hardness assumption of the modified k-CAA problem and the discrete logarithm (DL) problem.When an explicit long-term certificate is revoked, its status information (in the form of an explicit short-term certificate) is available online at the moment of signature generation.The method used for revoking and providing certificate status is similar to that presented by Yum et al. [29].
The implicit and short-term explicit certificates are two components of the signature key that can be used to sign documents.A signatory who wishes to reject the signatures he or she has generated may intentionally compromise his or her signature key and falsely claim that the signatures have been forged by someone else.Such a scenario is impossible with an explicit short-term certificate because the signer cannot revoke the explicit shortterm certificate used as part of the full signature key.
Using explicit short-term certificates ensures that revocation latency (i.e., a time lag between revoking the certificate and informing the relaying parties) is irrelevant, as the digital signature is valid only until the associated short-term explicit certificate expires.Because of the proposed signature validation approach based on the certificate validation shell model (see Section 1), the acceptance of such a signature should not pose any risk to a relaying party.
In our approach, a user's private key consists of a secret value, a long-term partial private key and a short-term explicit certificate (a time key).The first two partial keys are kept secret by the user, and their authenticity is confirmed by a long-term certificate issued by the trusted authority (TA).An explicit short-term certificate is periodically updated and sent over a public channel.To perform such an operation (unlike the cloud-based revocation server proposed by Jia et al. in Figure 1), we suggest using the trusted status authority (TSA), which issues a new short-term explicit certificate for each valid long-term explicit certificate and stops doing so when the long-term explicit certificate is revoked.
An explicit short-term certificate eliminates the need to generate CRLs used in traditional PKI systems; furthermore, it serves as non-repudiation evidence of a digital signature; 2.
During the signature creation process, a three-component user's private key is used; this approach allows Girault's trust level 3 security to be achieved; only the verification process, in addition to the public key and explicit signer's certificates, indirectly references other parties' keys, including TA keys; 3.
A signer's public key, as in the related two partial private keys, contains three component groups: the signer generates the first, while two others are created by trusted and trusted status authorities; 4.
The short-and long-term explicit certificates of a signer are public, i.e., these certificates are used in the signature verification process and to verify their authenticity and their validity; 5.
A signature verification process uses short-and long-term explicit certificates, where explicit short-term certificates play a role in the certificate status; 6.
The strongest security property for digital signatures is provided, i.e., existential enforceability against adaptively chosen message attacks.
Additionally, in the scheme, a user can only change his public and private keys with TA acceptance and vice versa.A TA cannot generate a false private key of any user to forge a signature without being detected by the user.Hence, the scheme fulfils Girault's level 3 security requirement.

Paper Organisation
In addition to the introductory section, this paper consists of four sections and two appendices.Section 2 introduces the concept of a signature scheme based on implicit and explicit certificates and its security model against three different attack types.Section 3 proposes a randomized IE-RCBSS-kCAA pairing-based signature scheme, and Section 4 analyses its security in a random oracle.Section 5 presents the analysis of the scheme's efficiency.The paper ends with conclusions.

Signature Scheme Framework Architecture and Its Security Model
This section describes the architecture framework of our IE-RCBS-kCAA signature scheme and its security model.The definitions of asymmetric bilinear map groups and the hard computational problems (discrete logarithm (DL) problem, kCAA problem, k-mCAA problem) can be found in Hyla et al. [30] and Mitsunari et al. [31].

Signature Scheme Framework
The architecture framework of the IE-RCBS-kCAA signature scheme is shown in Figure 1.This architecture involves three parties: the trusted authority (TA), the trusted status authority (TSA) and the users (signers and verifiers).At system initialization, the TA generates and publishes common parameters.The TSA can use these parameters to generate its secret master private status key or independently generate its parameters and then use them to generate the secret master private status key.This solution allows the TA and TSA to work in the first case in the same algebraic groups and the second in two different, independent ones.
Next, the TA issues the partial secret key for each registered user using its master system key.The TSA is an authentication service that decides the validity of an explicit long-term certificate at the current time and issues an explicit short-term certificate if the TSA answer is positive.Therefore, on request, the TSA checks the signer's long-term explicit certificate status according to the signed revocation list from the TA.The revocation list issued at time t by a trusted authority, TA, is denoted RL TA,t .This list contains the indexes of revoked long-term certificates and is updated periodically.Suppose a signer's long-term certificate is in the signed revocation list.In that case, the TSA can send back a revoked response with a long-term explicit certificate status value equal to revoked or refuse the request.Otherwise, it outputs good or unknown.This last state indicates that the TSA does not know the certificate being requested.
The trust model (understood as building trust relationships between cryptographic keys and their owner's identity) with the TSA, and separating its role from the TA role, allows various business models to be obtained that can provide certificate issuing services (explicit or implicit) and determine their status.In a particular case, the TSA may act as an independent third party and provide certificate status verification services to multiple TA authorities.This type of scenario aligns with the model that has long been used in PKI systems: CAs issue certificates, and the OCSP server issues certificates of their status [32].
Let us assume that the earlier mentioned trust authorities and trusted status authorities are part of the trust model based on a common set of system parameters.These parameters may include, among others, the same algebraic groups G 1 , G 2 and G T .It is easy to notice then that such an assumption allows us to effectively solve the scalability problem of the trust architecture shown in Figure 1 and to adapt it to many users.In that case, users can use not only many TSAs but also many TAs.However, this paper only considers the trust model with a single TA and TSA.
Definition 1 (IE-RCBS-kCAA scheme).An implicit and explicit certificates-based signature against k-traitors collusion attack scheme consists of the following eleven polynomial-time algorithms: TA-Setup (1 k ) → (s, params).A security parameter 1 k is an input and outputs the certifier's master private key s, the system parameters are params and a revocation list RL TA,thisU pdate (initially empty), where thisU pdate indicates the issue date of this RL, which are then properly distributed in the system.The TA runs the algorithm and, when completed, keeps the master private key s secret, while the RL and params are publicly available to the TSA and all other users on the system, respectively.
The TA runs the algorithm and, in secret, keeps the master private key s, while the RL and params are publicly accessible to the TSA and all other users in the system, respectively.
TSA-Setup (params) → (v, V 0 , T 0 ).The algorithm takes as input the system parameters params and outputs a master private status key v and two related TSA public keys (V 0 , T 0 ).
Create-User (params, ID s ) → (s ID s , P ID s ).The user runs the algorithm, and the input is the system parameters and the signer's identity.The output is the user's secret key value s ID s and the corresponding first partial public key P ID s .
Implicit-Cert-Gen (params, s, ID s , P ID s , τ lt ) → (CI ID s , iCert ID s , r ID s ).This algorithm takes as input the system parameter params, master private key s, the identity ID s of a user, its first partial public key P ID s and a certificate validity period τ lt .It outputs the user's certificate information CI ID s , an implicit certificate iCert ID s and the secret key r ID s used by the TA during the user's implicit and explicit certificates' generation that is unknown to this user.
The TA runs the algorithm once for each user, and the corresponding implicit certificate is distributed to the user secretly.
LongTerm-Explicit-Cert-Gen (params, s, CI ID s , r ID s , q ID s ) → (eCert ID s ).The input is the system parameter params, master private key s, the user's certificate information CI ID s , the secret key r ID s related to the user's implicit and explicit certificates, and the hash value q ID s .
The output is an explicit long-term certificate eCert ID s that is sent to the user by a public channel.A TA runs this algorithm once for each user.
ShortTerm-Explicit-Cert-Gen (params, v, V 0 , T 0 , bstr, CI ID s , eCert ID s , τ st ) → (e st Cert ID s , CSI ID s , I ID s ).This algorithm takes as input the system parameter params, a master private status key v and two related TSA public keys (V 0 , T 0 ), the bitstring bstr (e.g., related with the signed message), CI ID s and his/her long-term explicit certificate, and a period τ st .The TSA first checks the current RL It is required that if σ = Sign (params, m, CI ID s , Sk ID s , eCert ID ) then Verify (params, m, σ, CI ID s , CSI ID s , I ID s , eCert ID s , e st Cert ID s ) = true, where the public parameters params, the signer's private/public key pair (Sk ID s , Pk ID s ) and the long-and short-term explicit certificates (eCert ID s , e st Cert ID s ) are generated based on the specification of the algorithms: TA-Setup, TSA-Setup, Create-User, Implicit-Cert-Gen, LongTerm-Explicit-Cert-Gen and ShortTerm-Explicit-Cert-Gen.Remark 1. Implicit-Cert-Gen and Explicit-Cert-Gen algorithms are successful when the TA positively verifies the identity and certificate information of CI ID s confirming this identity.Furthermore, whenever a user requests a certificate for a public key P ID s , the user must prove the possession of the corresponding secret key s ID s to the certifier, similar to a traditional public key infrastructure.Similar remarks apply to ShortTerm-Explicit-Cert-Gen: a positive result of this algorithm is only returned for the associated valid long-term unencrypted certificate.

Security Model
The security proof of the proposed IE-RCBS-kCAA signature scheme is based on the commonly accepted standard security notion EUF-CMA (existential unforgeability under chosen message attack).The EUF-CMA notation guarantees the highest security level of the signature scheme and thus the resistance of the signature scheme against the strongest attacks of the adversary.
The security proofs is a claim made within the random oracle model, where a hash function finally replaces the random oracle.It is easy to see that the last step is heuristic in nature.In practice, the heuristics are successfully used for problem solving (e.g., [34][35][36][37]).However, the security proof in the oracle model can only be treated as a heuristic argument for the security of the cryptographic scheme, but without a guarantee for the security of its real implementation (Bellare and Rogaway [38]).
For the IE-RCBS-kCAA signature scheme, four cases of access or lack of access by an adversary to TA and TSA master keys should be considered: (a) An adversary does not know the TA and TSA master keys; (b) An adversary knows the TA and TSA master keys; (c) An adversary knows the TA master private key and does not know the TSA master private status key; (d) An adversary does not know the TA master private key TA and knows the TSA master private status key TSA.
Access to or lack of access to TA and TSA keys may depend on the adversary's knowledge or ignorance of different user keys.Consequently, this allows us to define five different types of adversaries, the capabilities of which are shown in Table 1.Each type of adversary has its role and access rights (yes/no) to the user's secrets or public key replacement.For example, the A 1 adversary is a user who has not yet been registered and does not have a certificate.The purpose of the adversary attack is to impersonate this type of user and forge his/her signature.It is assumed that the adversary does not have access to the TA and TSA master keys and to the implicit certificate of the target user but has access to his/her short-term explicit certificate, the secret key, and can change his public key.
Note that even if the A 1 , A 3 and A 4 adversaries cannot access the TSA's master private status key, it still provides them access to the explicit short-term certificate.The TSA is fair and acts as an oracle, responding to any correct requests unless they concern a revoked certificate.In the latter case, the adversary does not receive a valid short-term explicit certificate for the next period.However, acting as a user with the revoked implicit certificate, they can collude with other legal users and generate its correct value.
A thorough analysis of the adversary types and their capabilities in Table 1 shows that the adversaries A 1 and A 5 and A 2 and A 4 have equivalent capabilities to falsify the target user's signature.Hence, in the case of the proposed signature scheme with two trust authorities (TA and TSA), only three types of adversaries (A 1 , A 2 and A 3 ), should be considered.As a result, the security model is similar to the models proposed for invalidation signature schemes with a single trust authority (see, e.g., Y. Sun et al. [24] and Y. Huang et al. [39]).Based on the above comments, the security model of the proposed IE-RCBS-kCAA scheme, from now on referred to as EUF-IERCBS-kCAA-CMA, is defined by three games between challenger C and adversary A, assuming that the adversary chooses which game to play.In all cases, adversary A = (A 1 , A 2 , A 3 ) is trying to break the EUF-CMA security of the IE-RCBS-kCAA scheme, i.e., the formal model describing existential unforgeability.We use two types of adversaries with different capabilities: Type I adversary and Type II adversary (see, e.g., [3]) to describe the first two games.For the third type of adversary, i.e., Type III adversary, we adopt the security notation introduced by Y. Sun et al. [24] and Y. Huang et al. [39] that is necessary for the security proofs to come.Type I and II adversaries are similar to those defined in [30] and their descriptions are omitted here.Type III adversary (A 3 ) represents a revoked certified user whose long-term explicit certificate is no longer valid.However, it should be noted that a revoked user still holds her/his implicit certificate and related secret key.However, the TSA stops issuing the subsequent short-term explicit certificates to her/him.The adversary cannot gain the TA's master secret keys and the TSA's master private status key but can replace the public key of any user, except the target user, with a value of her/his choice.The security model categorises potential adversaries based on their attack capabilities and classifies Type I/II/III adversaries into three categories (see Li, J., et al. [40][41][42] and Huang, X., et al. [43]): Normal adversary, Strong adversary and Super adversary.The scheme should resist a Super Type I/II/III adversary (in Games I/II/III), who can obtain a valid signature under the public key chosen by itself without providing the corresponding secret.Definition 2. An implicit and explicit certificate revocable signature scheme IE-RCBS-kCAA has existential unforgeability against chosen message attacks (EUF-IERCBS-kCAA-CMA) if no probabilistic polynomial-time adversary has a non-negligible probability of winning Game I, Game II and Game III.

1.
TA-Setup: The system parameters are params = {G 1 , G 2 , G T , p, ê, for some prime number p ≥ 2 k (k is the system security number), (P, Q) are generators of, respectively, G 1 and G 2 such that ê(P, Q) = g, P 0 = sP and Q 0 = sQ, the system's master public keys with the master private key s ∈ Z * p , H 1 , H 2 : Γ → Z p and H 3 : {0, 1} * → Z p are three secure cryptographic hash functions.Γ means a string space that defines a user with the identity ID.When ID contains more information other than the identity, we mark it as CI or CSI.

2.
TSA-Setup (params): The TSA chooses a random number v ∈ Z * p as its master private status key and calculates its public keys V 0 = vP and T 0 = vQ.

3.
Create-User (params, ID s ): The user ID s chooses a random number s ID s ∈ Z * p , sets s ID s as the secret key and produces the corresponding first partial long-term public key P ID s = s ID s P. The secret key s ID s is kept secret, while the user sends P ID s to the TA over an authenticated channel.

4.
Implicit-Cert-Gen (params, s, ID s , P ID s , τ lt ): Given ID s presenting S's identity, his partial long-term public key P ID s and a period τ lt , the trust authority TA: (a) Randomly selects r ID s ∈ Z * p and computes respective second and third partial long-term public keys (R ID s , R " ID s ) = (r Composes the user's certificate information CI ID s , including the TA's public keys (P 0 , Q 0 ), identifiers ID s and ID TA of the user S and the TA, respectively, first, second and third partial public keys (P ID s , R ID s , R " ID s ), and the period τ lt for which the information CI ID s is valid; (c) For P ID s and (R ID s , R " ID s ) computes: (d) Generates S's partial private key (an implicit certificate): and transmits it to the user S secretly; in addition, TA sends CI ID s .

5.
LongTerm-Explicit-Cert-Gen (params, s, CI ID s , r ID s , q ID s ): The TA generates the signer's S explicit certificate using parameters provided by S and the values created when executing the Implicit-Cert-Gen algorithm: (a) The TA creates the explicit certificate that links S's identity with the public key components: The TA sends eCert ID s to an entity S.

6.
ShortTerm-Explicit-Cert-Gen (params, v, V 0 , T 0 , bstr, CI ID s , eCert ID s , τ st ): Taking as input any bitstring, the user's certificate information CI ID s and his/her long-term explicit certificate eCert ID s (created for the period τ lt ) and a period τ st , the TSA first checks if the user and his/her long-term explicit certificate are in the RL TA,t .If that is so, the TSA rejects the update request.Otherwise, the TSA: (a) Randomly selects secret key z ∈ Z * p and computes (Z , Z " ) = (zP, zQ); (b) Composes the certificate status information CSI ID s , including (Z , Z " ), the TSA public keys (V 0 , T 0 ), ID s and ID TSA identifiers, the status value equal to good, and the period τ st for which the information CSI ID s should be valid; (c) For CI ID s , an explicit certificate eCert ID s and CSI ID s computes: where Generates the explicit short-term certificate (the certificate status evidence) as: and transfers it to the user S via a public (open) channel; in addition, the TSA sends CSI ID s and I ID s .

7.
Set-Private-Key (params, CI ID s , CSI ID s , s ID s , iCert ID s , e st Cert ID s ): The user S calculates the hash values q ID s and t ID s (see Equations ( 1) and ( 4)), and checks if ê(q ID s R ID s + P 0 , iCert ID s ) = ê(t ID s Z ID s + V 0 , e st Cert ID s ) = ê(P, Q) = g; if in both cases the answer is positive, then the algorithm formulates a full private key in the form Sk ID s = (s ID s , iCert ID s , e st Cert ID s ).

8.
Set-Public-Key (params, CI ID s ): The user S with P ID s , R ID s and R " ID s (taken from the user's certificate information CI ID s ) sets his full long-term public key in the form Pk ID s = (P ID s , R ID s , R " ID s ).The TA publishes the resulting full long-term public key in its public repository and distributes it to all interested parties.9. Cert where If in ( 6) k 1 h + s ID s = 0, then repeat steps (a) and (b).
Note.Each time a signature is generated, a fresh short-term explicit certificate is retrieved from the TSA (cf.ShortTerm-Explicit-Cert-Gen algorithm).11.Verify (params, m, σ, CI ID s , CSI ID s , I ID s , eCert ID s , e st Cert ID s ): To verify the tuple containing the message, the signature and certificates, i.e., (m, σ = (h, w 1 , w 2 , E), eCert ID s , e st Cert ID s , I ID s ), V performs the following steps: (a) Computes q ID s (see Equation ( 1)) and then calculates values: If the status of the certificate eCert ID s in the certificate status information CSI ID s is correct and ( 8) is valid, then returns accept, otherwise reject.
Remark 2. Note that during the indirect signature verification, the long-and short-term explicit certificates are validated (eCert ID and etCert ID , respectively).This verification can also be performed directly based on the following formulas: If the conditions formulated in Equations ( 8)-( 9) are met, it means that a signature is mathematically correct.It is the first postulate for a digital signature to be valid.The second one applies to the validity of digital signatures at a semantical level that depends on the underlying validity model (Baier, H. et al. [1]).
Suppose we use a shell model and the verifier received the signature at time t v called the verification time.Assuming that the TA's master private key and the TSA's master private status key are irrevocable signature keys, the semantic validity of the digital signature depends on a short-and long-term certificate validity (e st Cert and eCert, respectively).Because both certificates are mathematically correct and (e st Cert, eCert) certificates are issued with respective periods τ lt = [τ i lt , τ e lt ], τ st = [τ i st , τ e st ] and expiry dates τ e lt , τ e st , then a verifier checks if: (a) e st Cert was certified by the TSA and the validity period τ st of e st Cert satisfies When the above conditions are successful, the signature will be accepted as valid short-period non-repudiation evidence in whole period Remark 3. Based on the properties of the asymmetric bilinear map groups: Hence, it follows that, alternatively, the execution of the LongTerm-Explicit-Cert-Gen algorithm can be entrusted to the signatory S, who, after receiving the implicit certificate from the TA will use Equation (10) to calculate the explicit certificate.

Correctness
The σ = (h, w 1 , w 2 , E) is a valid signature on message m because it is accepted by Verify.We state the proof as follows: Thus, Moreover, based on this, it is straightforward to prove the correctness of the long-term explicit certificate: and short-term explicit certificate:

Security Analysis
In Games I and II, the TSA is treated as an oracle that answers every query the challenger or adversary asks.It has been assumed that long-term certificates are not revoked in these two games.Therefore, all explicit short-term certificates issued by the TSA have the status good.In Game III, long-term certificates can be revoked.The TSA will not issue a short-term explicit certificate for the next validity period of τ st i .Because the adversary still owns the implicit and long-term explicit certificates, it can try to produce valid signatures even if the previous short-term explicit certificate is no longer valid.The adversary does not know its short explicit certificate for the new target period but can cooperate with legal users to obtain such a certificate.
We proved the IE-RCBS-kCAA scheme security by reducing the security of a higherlevel construction to a lower-level primitive.In particular, we reduced the existence of an adversary by transforming the protocol into an algorithm that solves the corresponding k-mCAA problem or the discrete logarithm (DL) problem with non-negligible probability.To this end, we used a general forking lemma (Bellare and Neven [44]), similar to [30].
Table 1 below shows that in comparison with the A 1 and A 3 adversaries, the A 2 adversary's capabilities are greater (if only because he/she has access to the master private key and master private status key that belong to the TA and TSA, respectively).On the other hand, the capabilities of A 1 and A 3 adversaries are similar: • A 3 knows the implicit certificates of users whose long-term explicit certificate has been revoked (in particular, it may be his/her certificate) but cannot obtain from the TSA any valid short-term explicit certificates related to them; the TSA will not respond to any request of the adversary to issue an explicit short-term certificate for the next period after the related long-term explicit certificate has been revoked; hence, the adversary, in order to forge the adversary's signature, must be able to calculate an explicit short-term certificate; • A 1 does not know the implicit certificates of users who were indicated as targets of the adversary attack; however, since, in this case, none of the explicit long-term certificates were revoked, the TSA responds to every request to issue (also from the adversary) a short-term explicit certificate for the next validity period; hence, the adversary A 1 knows the explicit short-term certificates of all users, including those who are the targets of the attack, but must calculate the corresponding implicit certificates.
In both cases, after creating a valid forged signature, the adversaries A 1 and A 3 disclose the corresponding short-and long-term explicit certificate.It follows that challenger C with the help of adversary A 1 or A 3 could solve the computing k-mCAA problem.However, this is contrary to the assumption that the k-mCAA problem is a computationally difficult problem.Hence, the proposed IE-RCBS-kCAA signature scheme is provably secure against Types I and III adversaries, as demonstrated in Lemmas 1 and 3, respectively.In Lemma 2, we also prove that IE-RCBS-kCAA is secure against a Type II adversary.Lemma 1. Suppose the hash functions H 1 , H 2 and H 3 are random oracles, and A 1 is a Type I adversary in Game I against the IE-RCBS-kCAA scheme.When the adversary A 1 has a nonnegligible advantage over the IE-RCBS-kCAA scheme, then there is a reduction R 1 that solves the k-mCAA problem over the G 2 group with non-negligible probability: where e is the base of the natural logarithm, q I , q E , cq S and γ = q H 3 are the upper bound on the number of queries sent to the respective Implicit-Cert-Gen-Query, LongTerm-Explicit-Cert-Gen-Query, Super-Sign-Query oracles and the H 3 -Query oracle.
Proof.(sketch) According to the approach given in [30] (also compare Lemma 3), our reduction consists of two phases.First, we apply the intermediate algorithm B 1 (i.e., the wrapper) that interacts with adversary A 1 and it returns a side output.Second, we build a reduction algorithm R 1 that launches general forking algorithm F B 1 with wrapper B 1 that handles the simulation of the IE-RCBS-kCAA scheme environment to the actual adversary.
The algorithm R 1 returns data that allow the correct solution of the k-mCAA problem to be obtained.Assume that B 1 is given a random instance = (G 2 , p, P, sP, Q, sQ, (s + r 1 q 1 ) −1 Q, . .., (s + r k q k ) −1 Q) of the k-mCAA problem, where G 2 is a group with a large prime order p.For the master private key s ∈ Z * p unknown to C and B 1 , the goal is to compute (r * q * + s) −1 Q for some q * / ∈ {q 1 , . . ., q k }, r * Q / ∈ {r 1 Q, . ..,r k Q}, and given q 1 , . . ., q k ∈ Z * p , r 1 Q, . ..,r k Q.In order to achieve this goal, we convert Type I adversary A 1 to algorithm B 1 (compare with Lemma 3).Finally, the reduction algorithm R 1 invokes a general forking algorithm F B 1 with the wrapper B 1 to solve the challenge .
Note that in comparison to Lemma 3, the simulation of ShortTerm-Explicit-Cert-Gen-Query is simpler because it is reasonable now to respond to each request of the adversary A 1 (no long-term certificate is revoked).What is more, this response is always provided by the TSA, which thus becomes a component of the simulation environment.
The success probability of a Super Type I adversary is calculated similarly to Lemma 3. We should consider the same four events ¬E 1 , ¬E 2 , ¬E 3 and ¬E 1 with one exception: the wrapper B 1 cannot fail during the simulation of the oracle ShortTerm-Explicit-Cert-Gen-Query.Finally, from the general forking lemma, the success probability ε R 1 k−mCAA can be expressed as in Equation (15).
This ends the sketch proof.
Next, in Game II, applied to the Super Type II adversary where the adversary models the certified entity, we require that signers are honest and the TA registers their tuples (ID, P ID , eCert ID ).The following lemma can be shown for this assumption with the use of a random oracle model: Lemma 2. Suppose the hash functions H 1 , H 2 and H 3 are random oracles, and A 2 is a Type II adversary in Game II against the IE-RCBS-kCAA scheme.When the adversary A 2 has a nonnegligible advantage over the IE-RCBS-kCAA scheme, there is a reduction R 2 that solves the DL problem over the G 1 group with non-negligible probability: where q R , q C and γ = q H 2 are the upper bound on the number of respective queries sent to the Public-Key-Replacement-Query, Corruption-Query and H 2 -Query oracles.
The proof is similar to the proof of [30] and is omitted here.
Lemma 3. Suppose the hash functions H 1 , H 2 and H 3 are random oracles, and A 3 is a Type III adversary in Game III against the IE-RCBS-kCAA scheme.When the adversary A 3 has a nonnegligible advantage over the IE-RCBS-kCAA scheme, there is a reduction R 3 that solves the k-mCAA problem over the G 2 group with non-negligible probability: where q I , q E , q T , q S and γ = q H 3 are the upper bound on the number of respective queries sent to the Implicit-Cert-Gen-Query, LongTerm-Explicit-Cert-Gen-Query, ShortTerm-Explicit-Cert-Gen-Query, Super-Sign-Query and H 3 -Query oracles.
Proof.We begin by describing the B 3 wrapper and next demonstrate how R 3 reduction invokes the F B 3 algorithm on the B 3 wrapper to solve the k-mCAA problem.Suppose the adversary A 3 can make q H 1 , q H 2 , q H 3 , q T and q S queries to hash functions H 1 , H 2 , H 3 , and the ShortTerm-Explicit-Cert-Gen-Query and Super-Sign-Query oracle.Algorithm R 3 is given a random instance = (G 1 , G 2 , p, P, sP, Q, sQ, (s + r 1 q 1 ) −1 Q, . .., (s + r k q k ) −1 Q) of the k-mCAA problem, where the master private key s ∈ Z * p is unknown to C and B 3 .The challenger C and direct algorithm R 3 are asked to calculate (r * q * + s) −1 Q for some q * / ∈ {q 1 , . . ., q k }, r * Q / ∈ {r 1 Q, . ..,r k Q}, and given q 1 , . . ., q k ∈ Z * p , r 1 Q, . ..,r k Q.
Assume we are also given t 1 , . . ., This allows us to simulate the ShortTerm-Explicit-Cert-Gen-Query behaviour for all unrevoked long-term implicit certificates.

The Wrapper
We demonstrate that Type III adversary A 3 can be converted to algorithm B 3 and then used to solve a random instance of the k-mCAA problem.Assume that γ = q H 3 and H = Z p .Wrapper B 3 takes as an argument with a set of random elements q 1 , . . ., q k ∈ Z * p and h 1 , . . ., h γ ∈ Z * p and returns a tuple (J, σ) where J refers to indices of the target H 3 query and where σ is the side output.B 3 maintains two counters ctr and cin, which are initially both set to one, and three lists L H 1 , L H 2 and L H 3 used to store the answers to the H 1 , H 2 and H 3 random oracle queries.Wrapper B 3 interacts with adversary A 3 as follows (Algorithm 1).

Algorithm 1 B 3 ( ).
Initialize. ctr = 1, cin = 1, lists L H 1 , L H 2 and L H 3 are empty.TA-Setup.B 3 sets P and Q as the generators of groups G 1 and G 2 , respectively, sets TA's master public keys (P 0 = sP, Q 0 = sQ) and TSA's master public status keys (V 0 = vP, T 0 = vQ).We assume that master secret keys s and v are unknown to everyone, including B 3 .Then, B 3 defines params = {G 1 , G 2 , G T , p, ê, P, P 0 , V 0 , Q, Q 0 , T 0 , H 1 , H 2 , H 3 } and sends them to the adversary A 3 .Queries: A 3 can query the following oracles polynomial number of times.
Algorithm R 3 obtains two valid signature forgeries σi = ( m, σ = ( ĥi , ŵ1,i , ŵ2,i , Êi ), CI, CSI, eCert, e st Cert ID , I ID ) (i = 0, 1) for the same message m, public key P ID , longterm explicit certificate eCert ID and short-term explicit certificate e st Cert ID .The following equation is applied based on two sets of side outputs σ 0 and σ 1 : ê ψ(I ID ), Ê0 Eventually, the k-mCAA problem solution is: where q * / ∈ {q 1 , . . ., q k } and r * Q / ∈ {r 1 Q, . . ., r k Q}.The probability that the R 3 algorithm will solve the k-mCAA problem has not yet been calculated.In accordance with the simulation results, the R 3 algorithm can compute the value of iCert ID if and only if the below events occur:   We denote the probability with which F B 3 succeeds during the first run as acc 3 .Since F B 3 succeeds during the first run when there is no interruption in the query phase (event E 1 does not occur) and when adversary A 3 creates a valid forgery (event E 2 does not occur), we have: Event ¬E 1 occurs only when the four following events for ¬E 1 happen: ¬E 11 : B 3 cannot terminate during oracle simulation Implicit-Cert-Gen-Query, which occurs with a probability of (1 − ζ) q I ; ¬E 12 : B 3 cannot terminate during oracle simulation LongTerm-Explicit-Cert-Gen-Query, which occurs with a probability of (1 − ζ) q E ; ¬E 13 : B 3 cannot terminate during oracle simulation ShortTerm-Explicit-Cert-Gen-Query, which occurs with a probability of (1 − ζ) q T ; ¬E 14 : B 3 cannot terminate during oracle simulation Super-Sign-Query, which occurs with a probability of (1 Then we obtain: where µ = q I + q E + q T + q S .In addition, the probability of adversary A 3 producing a valid forgery when event E 1 does not occur is equal to Pr[¬E 2 |¬E 1 ] = ε.
If events E 3 and E 4 do not occur, then the advantage of the algorithm R 3 in solving the k-mCAA problem is: Let g f rk be the probability at which F B 3 is successful.As event E 4 occurs when F B 3 fails: Based on the general forking lemma [30,44] for γ = q H 3 and |H| = p: The probability at which the event E 4 does not occur, when the event E 3 does not occur, is equal to the probability at which the coin's value of β valid forgeries is not equal to 0. Hence: Finally, the derivative R 3 of a successful solution to the k-mCAA problem is computed as described below: When p >> 1, the expression is maximised at ζ = 1/µ.Therefore: ε 2 γe(µ + 1) 2 = ε 2 γe((q I + q E + q T + q S ) + 1) 2

¬E 1 :
B 3 does not fail during the simulation; ¬E 2 : A 3 outputs a valid forgery;

¬E 3 :
F B 3 does not fail;

¬E 4 :
R 3 does not fail, i.e., in interaction with adversary A 3 outputs two valid forgeries with a coin value β of 1.
CI ID s , CSI ID s , s ID s , iCert ID s , e st Cert ID s ) → Sk ID s .The user runs this algorithm.The algorithm takes as input the system parameters params, user's certificate information CI ID s , the certificate status information CSI ID s , a secret key s ID s , an implicit certificate iCert ID s and a short-term explicit certificate e st Cert ID s , and returns the corresponding full user's private key Sk ID s = (s ID s , iCert ID s , e st Cert ID s ).CI ID s , eCert ID s ) → RL TA,thisU pdate : for an input tuple (CI ID s , eCert ID s ) with the explicit long-term certificate eCert ID s that is requested to be revoked, the TA verifies entity credentials, and if the entity is authorized successfully, then the TA revokes the certificate and places it on the signed revocation list RL TA,thisU pdate that is issued at thisUpdate.Sign (params, m, CI ID s , Sk ID s , Pk ID s ) → σ.The signer runs the Sign algorithm that generates a signature σ for the given input: the params, a message m, a user certificate information CI ID s and the user's full key pair (Sk ID s , Pk ID s ).CI ID s , CSI ID s , I ID s , eCert ID s , e st Cert ID s ) → {true, f alse}.Everyone can run the algorithm Verify to check the validity of a signature.Taking as input a message/signature pair (m, σ), a user's certificate information CI ID s , a certificate status information CSI ID s , an auxiliary public information I ID s , and long-and short-term explicit certificates (eCert ID s , e st Cert ID s ), it outputs true when σ is a valid signature.Otherwise, it outputs f alse.
TA,t .If the request concerns the non-revoked longterm explicit certificate, then the TSA outputs an explicit short-term certificate e st Cert ID s , the certificate status information CSI ID s and auxiliary public information I ID s that is sent to the user by a public channel.A TSA runs this algorithm once for each user's request.Set-Private-Key (params,Set-Public-Key (params, CI ID s ) → Pk ID s : the user S run the algorithm with the certificate information CI ID s .It returns the full long-term public key in the form Pk ID s = (P ID s , R ID s , R ID s ).Cert-Revoke (params, Verify (params, (m, σ),

Table 1 .
The adversary types with different capabilities.
-Revoke (params, CI ID s , eCert ID s ): The user with CI ID s or any other authorized entity sends to TA a tuple (CI ID s , eCert ID s ) with the explicit long-term certificate eCert ID s to be revoked.After verifying the entity credentials to revoke the certificate, TA revokes it and places it on a signed revocation list RL TA,t .10. Sign (params, m, CI ID s , Sk ID s , eCert ID s ): To sign a message m ∈ {0, 1} * , a signer S performs the following steps: Computes the hash value bstr = H 3 (m, k 1 P), and q ID s = H 1 (CI ID s ); (c) Generates a short-term explicit certificate by calling the ShortTerm-Explicit-Cert-Gen (params, v, V 0 , T 0 , bstr, CI ID s , eCert ID s , τ st ) → (e st Cert ID s , CSI ID s , I ID s ) , Pk ID i to check whether ID i = ID and if it is true returns a previously defined value P ID i .(b) else, B 3 selects s ID ∈ R Z p at random and calculates public key P ID = s ID P. B 1 returns P ID and stores the tuple ID i , s ID , P ID in the L U list. 2. H 1 -Query (CI ID i ).Algorithm B 3 maintains a list L H 1 of tuples CI ID i , P ID i , R ID i , R ID i , coin i , cin i , c i , C i , eCert ID i .If B 3 or A 3 queries H 1 , algorithm B 3 returns c i directly when L H 1 contains a tuple CI ID i , P ID i , R ID i , R ID i , coin i , cin i , c i , C i , eCert ID i .Else: (a) B 3 randomly selects c ∈ R Z * p and sets coin = C = eCert ID i =⊥ when the query is made explicitly by A 3 (⊥ denotes unknown fields to B 3 ); (b) coin, cin, c, C, eCert ID i is stored in L H 1 and returns c as the answer.3.H 2 -Query (CI ID i , eCert ID i , CSI ID s ).On receiving the H 2 query on (CI ID i , eCert ID i , CSI ID s ), algorithm B 3 looks up the list L H 2 .If the corresponding entry already appears in L H 2 with a tuple CI ID i , eCert ID i , P ID i , CSI ID s , Z ID i , Z ID i , cin i , coin i , t i , e st Cert ID i , I ID i , then B 3 responds with t i .Otherwise: (a) if the query is made explicitly by A 3 , B 3 randomly selects t ∈ R Z * p and sets coin = 1, e st Cert ID i = I ID i =⊥; (b) otherwise, B 3 first call H 1 -Query (CI ID i ) oracle and as a result takes a tuple CI ID i , P ID i , R ID i , R ID i , coin i , cin i , c i , C i , eCert ID i form L H 1 list.i. if coin i = 0, B 3 chooses t cin i ∈ {t 1 , . . ., t k } and sets t = t cin i , e st Cert ID i z k Q}, respectively; computes Z ID = ψ(Z ID ) and sets e st Cert ID i = I ID i =⊥; CI ID i , eCert ID i , P ID i , CSI ID s , Z ID i , Z ID i , cin i , coin i , t, e st Cert ID i , I ID i is stored in L H 2 and t is output as the answer.4.H 3 -Query (m, k 1 P, U, H 1 (CI ID i )).Algorithm B 3 maintains a list L H 3 of tuples m i , (k 1 P) i , U i , c i , ctr, w 2,i , h i , where c i =H 1 (CI ID i ).B 3 runs H 1 -Query (CI ID i ) and gets requested hash value c.For each request made on (m, k 1 P, U, c), algorithm B 3 returns h i directly when L H 3 contains tuple m i , (k 1 P) i , U i , c i , ctr, w 2,i , h i .Else, B 3 returns h = h ctr ∈ R Z * p as the output, adds tuple m i , k 1 P, U, c, ctr, ⊥, h to L H 3 and increments ctr by one.